1.1 Abstract

• The challenge - Analyse and improve (using provided datasets) the loan application process. Design innovative ideas to conduct analysis and develop sound and executable business solutions to enhance the customer loan application experience.
  
• The data - is a real life event log of the loan and overdraft approvals process from a bank. The log consists of 262,200 events and 13,087 cases.
  
• Event Log - log is provided in XES format, the XES format is a standard defined by the IEEE task force on process mining.

1.2 Business Process Mining

Process mining is one hot top which has attracted intense analysis in recent years and has a broad range of applications across different industries.
Process Mining is a process analysis method that aims to discover, monitor and improve real processes by extracting knowledge easily from available event logs in the systems of current information of an organization.

1.3 Tooling — bupaR

http://www.bupar.net/index.html
bupaR is an open-source, integrated suite of R-packages for the handling and analysis of business process data. It currently consists of 8 packages, including the central package, supporting different stages of a process mining workflow.

3.1 View at case level (A case represent a process of one loan application)

kable(head(cases[cases$trace_length < 10,],5))

p1 <- 
cases %>% ggplot(mapping = aes(x = trace_length)) + geom_density() + geom_vline(aes(xintercept = mean(trace_length)),colour = anz_color1) + 
  labs(x = "Length of Trace", y = "",title = "Distribution of Trace Length") + theme_minimal() 
p2 <-
cases %>% ggplot(mapping = aes(x = number_of_activities)) + geom_density() + geom_vline(aes(xintercept = mean(number_of_activities)),colour = anz_color1) +
  labs(x = "Number of Activities", y = "",title = "Distribution of Activities Number") + theme_minimal() 

p3 <-
cases %>% filter(final_status != "OTHER") %>% ggplot(aes(x = factor(final_status), y = duration_in_days)) + geom_boxplot() +
  labs(x = "Final Status", y = "",title = "Boxplot of Duration in Days") + theme_minimal() 

p4 <- events %>%
    trace_length("log") %>%
    plot
multiplot(p1, p4, p2,p3, cols = 2)

cat("The application process is always started with A_SUBMITTED, and can be end with 11 different activities, include A_DECLINED/A_CANCELLED/A_REGISTERED/")

## The application process is always started with A_SUBMITTED, and can be end with 11 different activities, include A_DECLINED/A_CANCELLED/A_REGISTERED/

3.2 View at activity level

activities <- activities %>% 
  mutate(act_type = ifelse(substr(activities$activity_id,1,2)  == "W_", 
                           "workItem",
                           ifelse(substr(activities$activity_id,1,2) == "A_",
                                  "application",
                                  ifelse(substr(activities$activity_id,1,2) == "O_",
                                         "offer",
                                         "other"))))
p1 <- 
activities %>% 
  ggplot(mapping = aes(x = activity_id, y = absolute_frequency, fill = act_type)) + 
  geom_bar(position = "dodge", stat = "identity") + 
  labs(x = "Activities", y = "Absolute Frequency", title = "View at avtivity level") +
  theme_minimal() +
  theme(axis.text.x = element_text(angle = 45, hjust = 1)) +
  scale_y_continuous(labels = scales::comma) + 
  geom_text(aes(label = absolute_frequency),vjust = 1.6, colour = "white", size = 2) +
  geom_vline(xintercept = c(3,4,5),colour = anz_color1, size = .5)

p2 <-
  activities %>% 
  filter(activity_id %in% c("A_APPROVED","A_CANCELLED","A_DECLINED")) %>% 
  ggplot(mapping = aes(x = activity_id, y = absolute_frequency)) + 
  geom_bar(position = "stack", stat = "identity", fill = anz_color1) +
  labs(x = "End states of applications", y = "Absolute Frequency", title = "Distribution of application final result") +
  theme_minimal() +
  scale_y_continuous(labels = scales::comma) + 
  geom_text(aes(label = absolute_frequency),vjust = 1.6, colour = "white", size = 4)

# multiplot(p1, p2,cols = 1)
p1

3.3 View at resource level

Each resource_id represent an employee who involved in the application process. Resource 53 works very hard, seems like it’s a robot.

p1 <-
resources %>% filter(absolute_frequency > 7000) %>% 
  ggplot(mapping = aes(x = resource_id, y = absolute_frequency)) + 
  geom_bar(position = "dodge", stat = "identity", fill = anz_color1) + 
  labs(x = "Resources", y = "Absolute Frequency", title = "View at resource level") +
  theme_minimal() +
  scale_y_continuous(labels = scales::comma) + 
  geom_text(aes(label = absolute_frequency),vjust = 1.6, colour = "white", size = 3)

p2 <-
events %>% filter(resource_id == 53, activity_id %in% c("A_SUBMITTED","A_PARTLYSUBMITTED","W_Afhandelen leads","W_Completeren aanvraag","A_DECLINED","A_CANCELLED")) %>%
  ggplot(mapping = aes(x = activity_id)) + geom_bar(fill = anz_color1) + 
  labs(x = "Activities", y = "Absolute Frequency", title = "Activity Distribution of Resource 53") +
  theme_minimal() +
  theme(axis.text.x = element_text(angle = 45, hjust = 1))

multiplot(p1, p2,cols = 2)

3.4 View at trace level

cat("There are ", nrow(traces), "unique traces; Let's look at the most frequent ones. (coverage = 50%)")

## There are  4366 unique traces; Let's look at the most frequent ones. (coverage = 50%)

cat("26.2% applications are declined directly; 14.3% applications are declined beacuse the applicant can't(or not able to) complete the online application")

## 26.2% applications are declined directly; 14.3% applications are declined beacuse the applicant can't(or not able to) complete the online application

trace_exp <- events %>%
  trace_explorer(coverage = 0.5, show_labels = F)
trace_exp

4.1 The whole process map

The process looks dizzying。

events %>% process_map()

4.2 Process at application level

Let’s only look at the process at application level:

events %>% filter_activity(c("A_SUBMITTED","A_PARTLYSUBMITTED","A_DECLINED","A_PREACCEPTED","A_ACCEPTED","A_FINALIZED","A_CANCELLED","A_ACTIVATED","A_APPROVED","A_REGISTERED")) %>%
  process_map()

final_status2 <- c("A_CANCELLED","A_Succeed","A_DECLINED")
fincal_count <- c(2807,2246,7635)
wf_data2 <- data.frame(final_status2,fincal_count)
wf_data2 %>% 
  ggplot(aes(x = final_status2, y = fincal_count)) + geom_bar(fill = anz_color1, position = "dodge", stat = "identity") +
  labs(x = "Final Status", y = "Count", title = "Final status of cases") +
  theme_minimal() +
  theme(axis.text.x = element_text(angle = 45, hjust = 1))

We can deep dive into the process step by step (application level activities) to get more detialed information, e.g. the following diagram shows processes between A_PARTLYSUBMITTED and A_PREACCEPTED

se_process_1 <- events %>% filter_trim(start_activities = "A_PARTLYSUBMITTED",end_activities = "A_PREACCEPTED") %>% process_map()
se_process_2 <- events %>% filter_trim(start_activities = "A_PREACCEPTED",end_activities = "A_ACCEPTED") %>% process_map()
se_process_3 <- events %>% filter_trim(start_activities = "A_ACCEPTED",end_activities = "A_FINALIZED") %>% process_map()
se_process_4 <- events %>% filter_trim(start_activities = "A_FINALIZED",end_activities = c("A_ACTIVATED")) %>% process_map()
se_process_5 <- events %>% filter_trim(start_activities = "A_FINALIZED",end_activities = c("A_APPROVED")) %>% process_map()
se_process_6 <- events %>% filter_trim(start_activities = "A_FINALIZED",end_activities = c("A_REGISTERED")) %>% process_map()
se_process_1

According to the conclusion above, we can simplify the process map as below by collapsing the reduntant activities:

events %>% filter_activity(c("A_SUBMITTED","A_PARTLYSUBMITTED","A_DECLINED","A_PREACCEPTED","A_ACCEPTED","A_FINALIZED","A_CANCELLED","A_ACTIVATED","A_APPROVED","A_REGISTERED")) %>%
  act_collapse(A_Success = c("A_ACTIVATED","A_APPROVED","A_REGISTERED"),
               A_SUBMITTED = c("A_SUBMITTED","A_PARTLYSUBMITTED")) %>%
  process_map()

The following diagram clearly shows the direct relationship betweeb two activities

events %>% filter_activity(c("A_SUBMITTED","A_PARTLYSUBMITTED","A_DECLINED","A_PREACCEPTED","A_ACCEPTED","A_FINALIZED","A_CANCELLED","A_ACTIVATED","A_APPROVED","A_REGISTERED")) %>%
  precedence_matrix(type = "absolute") %>% plot()

Accordingly, I have the following diagram to simplely show the standard process flow at application level and the number of cases at each phase:

4.3 Declined case

Now, I will deep dive into the declined cases, to discover the reasons of decline. From the above chart, we can know 5719 out of 7635 cases are declined immediately right after submission online.
Let’s check the other declined cases:

events_declined <- 
events %>% 
  filter_activity(c("A_PARTLYSUBMITTED","A_DECLINED","A_PREACCEPTED","A_ACCEPTED","A_FINALIZED","W_Afhandelen leads","W_Completeren aanvraag",
                    "W_Nabellen offertes","W_Valideren aanvraag","W_Nabellen incomplete dossiers","W_Beoordelen fraude","W_Wijzigen contractgegevens")) %>%
  filter_trim(start_activities = "A_PARTLYSUBMITTED",end_activities = c("A_DECLINED"))
events_declined %>% process_map(type = frequency())

Illustrate as:

In General, we can get the following chart to clearly show the applications final status - only 2246 out of 13087 got succeed.

x <- list("Total","CANCELLED","PREACCEPTED","Direct_Decline","Incomplete","Suspect_fraud","Completeren","Nabellen","Assessing","Qualified","ACCEPTED","Succeed")
measure <- c("Total","relative","relative","relative","relative","relative","relative","relative","relative","relative","relative","relative")
text <- c("13087","-2807","-399","-3429","-2234","-57","-1088","-86","-668","-48","-25","2246")
y <- c(13087,-2807,-399,-3429,-2234,-57,-1088,-86,-668,-48,-25,-2246)
wf_data <- data.frame(x=factor(x,levels = x),measure,text,y)

p <- plot_ly(
  wf_data, name = "20", type = "waterfall", measure = ~measure,
  x = ~x, textposition = "outside", y= ~y, text =~text,
  connector = list(line = list(color= "rgb(63, 63, 63)"))) %>%
  layout(title = "Applications final status",
         xaxis = list(title = ""),
         yaxis = list(title = ""),
         autosize = TRUE,
         showlegend = TRUE)
p

6.1 Mining of the dependency graph

A frequency based metric is used to indicate how certain that there is truly a dependency relation between two events/activities A and B (notation A ⇒W B). Let W be an event log over T, and a, b ∈ T. Then |a >W b| is the number of times a >W b occurs in W, and:
An sample to explain the mathematical formula
If we use this definition in the situation that, in 5 traces, activity A is directly followed by activity B but the other way around never occurs, the value of A ⇒W B = 5/6 = 0.833 indicating that we are not completely sure of the dependency relation (only 5 observations possibly caused by noise).
However if there are 50 traces in which A is directly followed by B but the other way around never occurs, the value of A ⇒W B = 50/51 = 0.980 indicates that we are pretty sure of the dependency relation.

Dependency graph of application process

dependency_matrix(events,threshold = .9) %>% render_dependency_matrix()

Causal graph / Heuristics net

causal_net(events) %>% render_causal_net()